The purpose of this PR is to support deprecating struct fields marked with relation tags in favor of polyrelation. For example, this struct fails to unmarshal in it's current form:

type Apple struct {}
type Orange struct {}

type Fruit struct {
  Apple  *Apple
  Orange *Orange
}

type Meal struct {
  ID          string  `jsonapi:"primary,meals"`
  Fruit       *Apple  `jsonapi:"relation,fruit"`
  FruitChoice *Fruit  `jsonapi:"polyrelation,fruit"`
}

This will work if the fruit struct is only ever of the following form:

type Fruit struct {
  Apple  *Apple
}

This is what we have in go-tfe in a handful of places. For example https://github.com/hashicorp/go-tfe/blob/98975f447700482a79e4d7d177cd406ff8132f1d/run_trigger.go#L59-L61

Most of the usages in go-tfe support polyrelation with a deprecated relation tag, but only one type in the associated polyrelation struct. See https://github.com/hashicorp/go-tfe/blob/98975f447700482a79e4d7d177cd406ff8132f1d/run_trigger.go#L59-L61

The issue is that as soon as you try to add another type to the polyrelation/choice struct, we start to run into unmarshal failures. This can be seen in the error handling workaround for DataRetentionPolicy in go-tfe Organization and Workspace: https://github.com/hashicorp/go-tfe/blob/98975f447700482a79e4d7d177cd406ff8132f1d/organization.go#L500-L505
Essentially what's happening here is that we aren't actually allowing a deprecated field to be adopted over time, but forces the library user to immediately adopt the breaking change.

This is a prerequisite to support hashicorp/go-tfe#1016